-
Notifications
You must be signed in to change notification settings - Fork 177
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stop filtering projects by ci.yml files #1564
Conversation
- This removes the ci.yml filtering which means all projects can be discovered - This eliminates the need for the yml parsing module for most common scenarios - This does introduce some potential issues with duplicate package names for languages like java. The only known case currently is azure-storage-blobs and if there is ever a need to explicitly pick the correct one someone can pass in the ServiceDirectory filter similar to "storage/azure*" for new and "storage/microsoft*" for the older sdk. By default azure usually comes first so the new one gets discovered which is likely all we need for now. If this turns out not to be true we might need another way to disambiguate.
This pull request is protected by Check Enforcer. What is Check Enforcer?Check Enforcer helps ensure all pull requests are covered by at least one check-run (typically an Azure Pipeline). When all check-runs associated with this pull request pass then Check Enforcer itself will pass. Why am I getting this message?You are getting this message because Check Enforcer did not detect any check-runs being associated with this pull request within five minutes. This may indicate that your pull request is not covered by any pipelines and so Check Enforcer is correctly blocking the pull request being merged. What should I do now?If the check-enforcer check-run is not passing and all other check-runs associated with this PR are passing (excluding license-cla) then you could try telling Check Enforcer to evaluate your pull request again. You can do this by adding a comment to this pull request as follows: |
Do we lose some control here around being able to make packages invisible to much of the engineering system when they are still getting set up? |
If we end up needing that control we might need to add it at the language-settings level because it will likely need to be filtered independently for different languages. So I suggest some outside filtering mechanism. |
The following pipelines have been queued for testing: |
Hello @azure-sdk! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
languages like java. The only known case currently is azure-storage-blobs and
if there is ever a need to explicitly pick the correct one someone can pass
in the ServiceDirectory filter similar to "storage/azure*" for new and "storage/microsoft*"
for the older sdk. By default azure usually comes first so the new one gets discovered
which is likely all we need for now. If this turns out not to be true we might
need another way to disambiguate.